Вчера мы писали о новой версии решения для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.12. Частью этого решения (помимо клиентов) является также продукт Dynamic Environment Manager 9.11, обновление которого вышло на днях. Напомним, что так теперь называется решение по управлению пользовательскими окружениями на уровне ОС, которое ранее носило название VMware User Environment Manager.

В версии Dynamic Environment Manager 9.10 был добавлен механизм настроек умных политик на базе компьютеров - computer-based Horizon Smart Policy (подробнее тут):

Теперь же появилась возможность переопределения политик. Политики computer-based применяются при запуске системы. С помощью значения RefreshInterval можно контролировать, как часто эти настройки будут обновляться, до того, как пользователь залогинится в систему. А с помощью значения ContinueRefreshAfterLogon можно продолжать обновлять настройки и после логина пользователя.

Ну и заключительная интересная новая возможность DEM 9.11 - это поиск элементов (Find Items). Он позволит искать в шаблонах конфигурации доступных в Marketplace, в созданных вами политиках Horizon Smart Policy, в определенном наборе условий (condition set) и других элементах, что очень удобно для администраторов:

Скачать Dynamic Environment Manager 9.11 можно по этой ссылке. Release Notes доступны тут.

В декабре прошлого года мы писали о выпуске обновленной версии платформы для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.11. Тогда в продукте появилось весьма много новых возможностей, если учитывать, чего его версия увеличилась всего на 0.01. На днях, после больших релизов VMware vSphere 7, vSAN 7 и vRealize Operations 8.1, компания VMware анонсировала новую версию Horizon 7.12, которая следует традиции прошлого выпуска - небольшое увеличение версии, но довольно много новых возможностей.

Одновременно с апдейтом Horizon 7.12 были обновлены и все клиенты до версий VMware Horizon Clients 5.4.

Давайте посмотрим, что именно интересного появилось в VMware Horizon 7.12:

1. Обновления платформы

В этой категории были сделаны следующие улучшения:

• Возможности назначения нескольких пользователей одному полному клону десктопа (Multi-User Assignment). Это пригодится для сменных рабочих, разработчиков и тестеров, а также персоналу поддержки. Это может применяться к автоматическим пулам, содержащим полные клоны ВМ, ручным пулам, а также пулам мгновенных клонов (instant-clone).
• Отображение имени машины в Horizon Client, когда пользователь логинится на хост, вместо имени пула.
• Новые и обновленные функции REST API предоставляют новые возможности автоматизации, где теперь есть 50 новых endpoints, таких как службы Image Management Service, Universal Broker, Configuration и Inventory.

• Новый временной лимит подогретых сессий позволяет еще больше сократить время логина. Первый логин за день занимает больше всего времени, чем остальные входы в гостевую ОС в течение дня. Теперь и первый логин происходит очень быстро, для этого Prewarm Time Limit составляет 30 минут по умолчанию.
• MAC-адреса теперь сохраняются в случае, если пул мгновенных клонов или ферма RDSH ресинхронизируется или делает операцию Refresh. Также есть поддержка SDDC из одного хоста для VMware Cloud on AWS, поддержка vmCrypt и мгновенных клонов в vSphere 7.0. Это все тоже очень удобно для сменных работников, использующих один десктоп.

2. Публикуемые приложения

В этой категории появилось одно улучшение - VM Hosted Applications. Оно позволяет предзапустить приложение в десктопе или пуле RDSH перед тем, как пользователь открывает приложение в Horizon Client. Это позволяет ускорить запуск приложений. Временной лимит настраивается через групповую политику.

3. Улучшения Horizon Console

• Для опубликованных приложений (RDSH и VM hosted applications) видно число пользователей их использующих и общее число возможных пользователей.
• Для каждого Connection Server можно посмотреть число сессий gateway и non-gateway.
• Дэшборд Summary Detail отображает детальные статистики так же, как и старая FLEX-консоль.
• Возможность использования принудительной Force 2-Factor реаутентификации (после истечения срока действия пользовательской сессии).
• Агрегированная статистика узлов Cloud Pod теперь представлена в отдельном разделе, где видно число используемые и брокерируемых сессий для всех узлов.
• Поддержка нескольких вкладок для Horizon Console, что очень удобно для администратора.
• В утилите Horizon Help Desk Tool можно искать процессы или приложения в сессии по имени (в поле filter).

4. Пакет Horizon GPO Bundle

• Возможность/невозможность использования существующего экземпляра клиента при соединении с тем же сервером.
• Настройка параметра HEVC High Color Accuracy.
• Настройки UDP применяются теперь при завершении сессии, а не при перезагрузке.
• Возможность отключить перенаправление принтера для недесктопного клиента.
• Настройка имени принтера для агентов RDSH.
• Возможность настройки списка URL Redirection whitelist.

5. Новые возможности клиентов

• Windows Client
  • Возможность использовать вложенные виртуальные машины Windows 10 1909 и server 2019
  • Улучшения пользовательского интерфейса
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• iOS Client
  • Поддержка Derived Credentials ActivClient
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Mac Client
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Linux Client
  • Поддержка Red Hat 8.1
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Настройка клиента для передачи клавиши ESX в рабочий стол Windows гостевой ОС
  • Возможность перезапуска VDI сервисов из клиента
  • Поддержка перенаправления URL
  • Синхронизация клавиши
  • Поддержка WVD для Horizon Cloud on Azure

• Chrome Native
  • Поддержка Derived Credentials ActivClient
  • Поддержка Horizon Universal Broker
  • Поддержка VMware Integrated Printing
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Arc++ Chrome Client
  • Поддержка Derived Credentials ActivClient

• Windows 10 UWP Client
  • Поддержка Horizon Universal Broker

• Android Client
  • Поддержка Horizon Universal Broker
  • Больше настроек для консоли Google Admin
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure
  • Поддержка перенаправления USB

• HTML5 Client
• Поддержка Horizon Universal Broker
• Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
• Поддержка WVD для Horizon Cloud on Azure
• Нативный запуска клиента HTML Access
• UAG 3.8+

Скачать VMware Horizon 7.12 можно по этой ссылке. Release Notes доступны тут.

На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.

Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:

1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:

vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.

2. Службы Native File Services for vSAN

С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.

3. Развертывание приложений с использованием Enhanced Cloud Native Storage

Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.

4. Прочие улучшения

Тут появилось довольно много нового:

• Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
• Immediate repair operation after a vSAN Witness Host is replaced. Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
• Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
• Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
• Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
• Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
• Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
• Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
• Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN. Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.

Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.

На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.

Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.

1. Улучшения сервисов VMware vCenter

Здесь можно отметить упрощение топологии vCenter Server SSO:

• Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
• Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.

Профили vCenter Server Profiles:

• Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.

Функции vCenter Multi-Homing:

• Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.

Улучшения Content Library

• Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
• Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.

Новая функция vCenter Server Update Planner:

• Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
• С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
• Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.

2 Улучшения механизма VMware DRS

• Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
• Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
• Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
• Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
• Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.

3. Улучшения vMotion

Тут появились такие улучшения:

• Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
• Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
• Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.

4. Новые функции vSphere Lifecycle Manager (vLCM)

Здесь можно отметить 2 улучшения:

• Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
• Первоначальная поддержка решений Dell OpenManage и HP OneView.

5. Возможности Application Acceleration (Tech Preview)

Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.

6. Функции Assignable Hardware

Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.

7. Управление сертификатами

Здесь 2 основных новых возможности:

• Новый мастер импорта сертификатов.
• Certificate API для управления сертификатами с помощью сценариев.

8. Возможности Identity Federation

Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.

9. Функции vSphere Trust Authority (vTA)

• vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
• Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
• Можно использовать механизм аттестации, когда требуются ключи шифрования.
• Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.

10. Возможность vSGX / Secures Enclaves (Intel)

• Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
• Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.

11. Новое издание vSphere with Kubernetes (Project Pacific)

О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.

Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.

12. Улучшения VMware Tools

Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).

13. Обновленное железо (VM Hardware v17)

Тут основные улучшения таковы:

• Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
• Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.

14. Улучшения vSphere Client

Здесь появились следующие улучшения:

• Начала сохраняться история поиска.
• В API Explorer теперь лучше видны все доступные API.
• Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.

Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.

Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги аренды виртуальных машин из облака по модели IaaS. Все меньше открытий делается случайно. Ученые современности редко совершают старые-добрые глупости: никто не забывает на столе чашки Петри, не топит буржуйку каучуком, не катается под кислотой на велосипеде, а если это и происходит, то без заметного эффекта на мировой прогресс.

В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.

Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.

Посмотрим на пример:

Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.

В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.

На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.

StarWind HCA All-Flash

Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.

Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:

• Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
• Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
• Безопасное резервное копирование виртуальных машин
• Катастрофоустойчивость на уровне площадок
• Максимизация производительности за счет RDMA
• Распределенное кэширование
• Проактивная поддержка вашей инфраструктуры специалистами StarWind
• И многое, многое другое

Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:

После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.

Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.

Новый StarWind Virtual SAN V8 для Hyper-V

Второй важный релиз - это обновленная версия продукта StarWind Virtual SAN V8 for Hyper-V (билд 13481 от 25 февраля 2020 года).

Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:

Ядро продукта

• Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
• Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
• Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
• Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
• Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
• Максимальное число лог-файлов в ротации увеличено с 5 до 20.

• Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
• Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
• Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
• Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.

• Реализована поддержка SMTP-соединений через SSL/STARTTLS.
• Добавлена возможность аутентификации на SMTP.
• Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.

• Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
• Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
• Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
• Исправлены ошибки в настройках CloudReplicator Settings.

• Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
• Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
• Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
• VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
• Свойство "Valid" добавлено к HA channel.
• Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
• Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).

• Небольшие улучшения и исправления ошибок.

Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.

В конце января мы писали о средстве Power vRA Cloud, которое позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. На днях вышло обновление этого PowerShell-модуля - Power vRA Cloud 1.1.

Помимо множества исправлений ошибок, в утилите появилось несколько новых командлетов:

• Add-vRA-Project-Administrator
• Add-vRA-Project-Member
• Get-vRA-DeploymentFilters
• Get-vRA-DeploymentFilterTypes
• Get-vRA-FabricNetworksFilter
• Get-vRA-FabricImagesFilter
• Remove-vRA-Project-Administrator
• Remove-vRA-Project-Member
• Update-vRA-Project-ZoneConfig

Напомним, что этот модуль не поддерживается со стороны VMware (как и все утилиты на VMware Labs, находящиеся в статусе Tech Preview), поэтому используйте его осторожно.

Скачать Power vRA Cloud можно по этой ссылке. Документация по использованию данного средства скачивается вместе с самим модулем.

Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.

К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:

Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:

$flasharray = new-pfaarray -endpoint 10.21.202.60 -credentials (get-credential) -ignoreCertificateError

Далее можно записать эту переменную в дефолтные параметры:

$PSDefaultParameterValues = @{
 "*-pfa*:Array"=$flashArray;

  }

Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).

Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:

$psCMDs = (get-command -Module PureStoragePowerShellSDK).Name

  $defaultParamHash = @{}

  foreach ($psCMD in $psCMDs)

  {

$defaultParamHash.Add("$($psCMD):Array",$flashArray)

}

$PSDefaultParameterValues = $defaultParamHash

После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:

Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.

Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

<Item>

   <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>

   <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

   <rasd:Connection>Network 1</rasd:Connection>

   <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
   <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>

   <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

   <rasd:ResourceType>10</rasd:ResourceType>

</Item>

Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:

https://[адрес VCSA]:5480

В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

https://[адрес VCSA]:5480

После развертывания эта возможность будет доступна на открывшейся странице:

На сайте проекта VMware Labs обновилось средство App Volumes Entitlement Sync до версии 2.3. Это решение позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.

Напомним, что о версии App Volumes Entitlement Sync 2.2 мы писали вот тут, давайте посмотрим, что нового появилось в версии 2.3:

• Исправлена периодически возникающая ошибка "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
• Если AppStacks на источнике и назначении не совпадают, показывается соответствующее сообщение
• В списке назначений показывается префикс монтирования
• Версия App Volumes 4.0 пока не поддерживается, ее поддержка будет добавлена в следующей версии

Скачать VMware App Volumes Entitlement Sync 2.3 можно по этой ссылке.

Свершилось. Компания Veeam Software, лидер в сфере средств для обеспечения доступности виртуальных датацентров, объявила о выпуске и доступности для загрузки новой версии пакета Veeam Availability Suite v10, в состав которого входит решение для резервного копирования и репликации виртуальных машин Veeam Backup and Replication v10.

Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.

Вот эти дашборды:

• Grafana vSphere Overview Dashboard – 8159
• Grafana vSphere Datastore Dashboard – 8162
• Grafana vSphere Hosts Dashboard – 8165
• Grafana vSphere VMs Dashboard – 8168

Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:

• Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - фреймворк, который используется для визуализации метрик из базы.

О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:

1. vSphere Overview Dashboard.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.

Лайв-демо такого дэшборда доступно по этой ссылке.

2. vSphere Datastore Dashboard.

Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

3. vSphere Hosts Dashboard.

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

Лайв-демо такого дэшборда доступно по этой ссылке.

4. vSphere VMs Dashboard.

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

5. vSphere Hosts IPMI dashboard.

Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.

Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:

• Grafana Dashboard for Veeam Availability Console - SP Overview
• Grafana Dashboard for Veeam Availability Console - Tenant Overview
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0 - Security and Performance
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v4

Ну в заключение, стоит отметить еще один дэшборд автора - Microsoft Azure Storage.

Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.

На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.

В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.

Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:

// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);

А вот так можно вывести список всех тэгов для конкретной виртуальной машины:

$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)

Больше интересных практических приемов работы с тэгами вы найдете в приложении к документу VMware vSphere 6.7 Tagging Best Practices.

Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:

В консоли браузера Chrome можно увидеть вот такую ошибку:

Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID

Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:

1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке: 

https://<current-hostname>/ui/#/host/networking/netstacks/defaultTcpipStack

2. Изменяем настройки хоста.

Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.

3. Идем по ssh на хост ESXi и выполняем там следующие команды:

cd /etc/vmware/ssl
/sbin/generate-certificates

Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.

4. Перезапускаем службу хоста ESXi:

/etc/init.d/hostd restart

После этого vSphere Client через Chrome 80 должен работать без проблем.

Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей предприятиям услугу аренды виртуальных машин из облака.

В каких условиях сегодня находится бизнес? С каждым годом растет конкуренция, и, чтобы оставаться в выигрышном положении, нужно соответствовать требованиям рынка. Внедрение современных ИТ-технологий, в том числе облачных, позволяет организациям перестраивать бизнес-процессы, существенно ускоряя производство. Очевидно, что трансформация, которую переживают многие компании, дает возможность конкурировать и достигать значимых результатов.

Но так было не всегда. 10 лет назад российский рынок жил другими стандартами: преобладал подход, когда предприятия строили и сопровождали ИТ-инфраструктуру силами штатных специалистов, сами закупали оборудование и не задумывались о переносе даже части сервисов вовне. Перенос ИТ-инфраструктуры целиком даже не обсуждался.

Со временем ситуация изменилась. Компании стали чаще уходить от on-premise-инсталляций и выносить на площадки провайдера критичные сервисы, от которых напрямую зависит деятельность предприятия. Теперь облачные технологии стали привычным инструментом. Выросло доверие к локальным провайдерам, поскольку они успели накопить экспертизу и перенять опыт у западных коллег.

Цифровая трансформация производства на примере компании Jotun

Считается, что производственная сфера довольно консервативная...Читать статью далее->>

На портале VMware Labs появилась очередная новинка - PowerShell-модуль Power vRA Cloud, с помощью которого можно отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. Поэтому с помощью данного средства можно разрабатывать сценарии по управлению облачной инфраструктурой VMware vRealize Automation Cloud с помощью PowerShell вместо прямой работы с API.

Сразу надо сказать, что этот модуль не поддерживается со стороны VMware (как и все утилиты на VMware Labs, находящиеся в статусе Tech Preview), поэтому используйте его осторожно.

После скачивания zip-файла с VMware Labs, распакуйте его и импортируйте модуль командой:

Import-Module .\PowervRACloud.psd1

Далее можно вывести список всех доступных функций:

Get-vRACloudCommands

Для соединения с инфраструктурой vRealize Automation используйте следующую команду (формируем токен как безопасную строку):

$APIToken = Read-Host -AsSecureString

Потом передаем этот API-токен при соединении:

Connect-vRA-Cloud -APIToken $APIToken

Ну а дальше можно использовать API, например, можно вывести аккаунты vRA командой:

Get-vRA-CloudAccounts | Format-Table

Скачать Power vRA Cloud можно по этой ссылке.

На сайте проекта VMware Labs появилась новая версия мобильного клиента для управления платформой VMware vSphereс мобильного телефона - vSphere Mobile Client 1.9.1 (а немногим ранее вышла версия 1.9). Напомним, что прошлая версия клиента vSphere Mobile Client 1.6 была выпущена в октябре прошлого года.

Давайте посмотрим, что нового появилось в мобильном клиенте за последнее время:

• Возможность сохранить информацию о доступе к vCenter Server (адрес сервера и имя пользователя).
• Возможность использовать распознавание FaceId или доступ по отпечатку пальца для логина на сервер vCenter.
• Добавлено быстрое действие выключения хоста ESXi.
• Улучшена совместимость с движком автозаполнения в полях ввода логина.
• Исправлены мелкие баги прошлых версий.

Скачать обновленный vSphere Mobile Client 1.9.1 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.

В целом, инициатива эта позитивная - она согласуется с оповещением безопасности CVE-2017-8563, которое говорит о том, что незащищенная коммуникация LDAP может быть скомпрометирована. Поэтому, начиная с марта, любая LDAP-коммуникация, которая не использует TLS, потенциально может быть отвергнута Windows-системой. Почитайте, кстати, об этой суете на Reddit.

Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.

Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).

Проверить текущую интеграцию с LDAP в vCenter можно в разделе Configuration -> Identity Sources:

Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.

После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:

Invalid Credentials

При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:

Check the network settings to make sure you have network access to the identity source

Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.

Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:

• 2020 Microsoft LDAP channel binding and LDAP signing requirement for Windows
• ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
• Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure
• How to enable LDAP signing in Windows Server 2008
• CVE-2017-8563 | Windows Elevation of Privilege Vulnerability

Документ о настройке LDAP Signing в Windows Server 2008 говорит, что вам надо изменить групповую политику "Default Domain Policy" (для домена), а также "Default Domain Controllers Policy" (для контроллеров домена), после чего дождаться ее обновления или обновить ее командой gpupdate /force.

Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).

Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:

Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:

После этого вы должны увидеть ошибку "Error 0x2028 A more secure authentication method is required for this server", которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:

Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.

О настройке сервера vCenter для LDAPS рассказано вот тут. Единственное, что вам потребуется - это добавить рутовый сертификат для сервера vCenter, который можно вывести следующей командой (если под Windows надо будет поставить Open SSL, под Linux утилита уже встроена):

echo | openssl s_client -showcerts -connect <FQDN>:636

Далее скопируйте все данные между "—–BEGIN CERTIFICATE—" и "—–END CERTIFICATE—–", после чего сохраните это в текстовый файл.

Никакой срочности до марта нет, поэтому не нужно суетиться и обновлять все Identity Sources, но разрабатывать план по переходу на LDAPS и тестировать его нужно уже сейчас. Будет неприятно, если пользователи неожиданно столкнутся с проблемой аутентификации. И да, откладывать обновления Windows не вариант - это единственный способ своевременно закрывать дырки в сфере информационной безопасности для вашей компании.

Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.

1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.

Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).

В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.

2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).

Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.

Также будет не лишним выполнить тест сети управления - опция Test Management Network. Ошибки, возникающие при этом, помогут понять, что случилось:

3. Проверьте, что со стороны vCenter Server у вас есть соединение с хостом ESXi - как по IP, так и по FQDN.

Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:

4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.

Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.

Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:

В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.

Ваша задача - обеспечить коммуникацию хоста ESXi с сервером vCenter по порту 902 (TCP/UDP):

Проверить коммуникацию по порту 902 можно с помощью Telnet.

Также тут вам могут помочь следующие статьи базы знаний VMware:

• Verifying the vCenter Server Managed IP Address (1008030)  
• ESXi 5.0 hosts are marked as Not Responding 60 seconds after being added to vCenter Server (2020100)
• ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630) 
• ESX/ESXi host keeps disconnecting and reconnecting when heartbeats are not received by vCenter Server (1005757)

Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.

5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.

Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:

Потом просто добавьте хост ESXi в окружение vCenter снова.

6. Если ничего из этого не помогло - время заглянуть в логи.

В первую очередь надо посмотреть в лог агента vpxa (/var/log/vpxa.log), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:

[2007-07-28 17:57:25.416 'Memory checker' 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 'Memory checker' 3076453280 info] Resource checker stopped.

Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd (/var/log/vmware/hostd.log), как описано в KB 1002849. Например, там может быть вот такая ошибка:

2014-06-27T19:57:41.000Z [282DFB70 info 'Vimsvc.ha-eventmgr'] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive

Ошибки могут вызывать разные причины, но наиболее частая из них - нехватка ресурсов для сервиса hostd.

7. Последнее, но не менее важное - проверить, нет ли проблем с хранилищем.

Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):

Вывод

Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.

Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.

В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.

Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.

Собственно, сам постер:

Второй интересный постер - это vRealize Network Insight Search Poster for Kubernetes. Он позволит вам найти объекты нативной инфраструктуры Kubernetes или развернутой на платформах VMware PKS или OpenShift.

Итого все постеры по функциям поиска в решении vRNI вы можете скачать по этим ссылкам:

• Kubernetes Search Poster
• SD-WAN & VeloCloud Search Poster
• NSX for vSphere Search Poster
• Network Flow Search Poster
• Virtual Machine Search Poster

Компания VMware выпустила новую версию решения App Volumes 4. Напомним, что решение App Volumes предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. О бета-версии четвертого поколения технологии App Volumes мы писали вот тут, а на днях вышел ее финальный релиз.

Давайте посмотрим, что там появилось интересного:

1. Новые возможности упрощенного управления приложениями

Теперь вместо объектов AppStacks, как это было в App Volumes 2.x, пользователи работают со следующими объектами:

1. Applications – вы сначала создаете приложение. Оно содержит в себе одну или несколько версий упакованного программного продукта. Назначения прав пользователям, группам, компьютерам или организационным единицам производится на уровне приложения. Назначения могут быть также сделаны внутри определенных пакетов.
2. Packages – после создания приложения вы используете packaging VM для сбора изменений, которые приложение вносит на диск, для того, чтобы подготовить его к распространению для пользователей и компьютеров. Это тот же процесс, что и был при создании AppStacks. Пакеты назначаются на стадии создания, после чего они могут идти по стадиям жизненного цикла.
3. Programs – после создания пакета происходит автогенерация программы. Название программы назначается автоматически. Одна программа может содержать или несколько установщиков приложений.

Такая архитектура дает большую гибкость и гранулярность при управлении приложениями:

Например, при выходе новой версии приложения, вы можете добавить нужный Package в уже существующий объект Application и доставлять его нужным пользователям.

С другой стороны, такая модель позволяет управлять приложениями на уровне иерархии организации. Например, можно создать Application для отделов маркетинга, где будут отдельные пакеты для каждого отдела. А уже на уровне отдела сделать сборки (Program) для каждого из случаев (например, роль пользователя на уровне отдела):

2. Новая функция сосуществования приложений старых версий

Приложения версии 2.x, сделанные как App Stacks, могут сосуществовать с новыми приложениями версии 4.x (Applications/Packages) в рамках административной консоли App Volumes 4. Для этого в консоли сделана специальная вкладка для 2.x приложений, которые вы можете постепенно перетаскивать на новую версию платформы.

3. Дополнительные функции

В этой категории появились следующие улучшения:

• Application Owners – вы можете назначить сущности Active Directory для обозначения владельца конкретного приложения.
• Application History – вы можете посмотреть список административных действий, выполненных с приложением, и кто их выполнил.
• Intent-based Assignments with a Current Marker – вы можете обозначить один из пакетов приложения как текущий, чтобы обозначить, что именно данная версия будет доставляться пользователям.
• Single-app Package Format – приложения теперь можно распространять в рамках одного пакета, которые можно комбинировать как угодно и в рамках конфигурации с несколькими VMDK-дисками в процессе доставки пользователям.
• Package Lifecycle Stages – теперь для пакета можно видеть стадии его жизненного цикла (New, Tested, Published или Retired).
• Package Notes – можно отслеживать детали пакета, путем добавления заметок о требуемой специфике или конфигурации приложения, после того, как вы закончили упаковку приложения в пакет.
• Improved Template Management – файлы Template policy (cfg) теперь переместились из шаблона диска в базовый образ, поэтому их можно просто апдейтить путем обновления агента. App Volumes Manager предоставляет интерфейс для загрузки и обслуживания шаблонов.
• Upgrading – можно обновить App Volumes Manager с версии 2.18 или более поздних, но продолжать управлять агентами 2.x (более подробно об этом рассказано в документации).
• Prevent Modifications to Installed Applications (в стадии Tech Preview) – некоторые из пользователей могут иметь возможность изменять или деинсталлировать приложения из базового образа. Это может иметь последствия в виде влияния на writable volume, который привязан к другой ВМ с таким же приложением (и вызвать непредсказуемые последствия). Поэтому администратор может запретить модификации приложений пользователями (по умолчанию такая функция отключена).
• AppStack Migration Tool – это специальная утилита, которая позволяет мигрировать объекты AppStacks 2.x на пакеты приложений (Packages) версии 4.x. Более подробно о App Volumes Migration Utility мы расскажем в ближайшее время.

Жизненный цикл распространяемого через App Volumes 4.0 приложения теперь выглядит следующим образом:

• Администратор создает приложение нужной версии и сохраняет метаданные, которые отражают параметры окружения, в котором пакет создавался.
• С помощью App Volumes и ThinApp администратор убеждается, что данная версия приложения работает в разных ОС и не конфликтует с другими приложениями.
• В пилотной среде происходит тестирование данной версии приложения на некотором наборе релевантных пользователей.
• Если тестирование прошло успешно, происходит публикация приложений в производственной среде. Назначение прав происходит тем же образом, что и в старом App Volumes версий 2.x.
• После выхода новых обновлений происходит списание старой версии приложений App Volumes.

Также по всем функциям App Volumes 4 можно пройтись в рамках интерактивного walk-through:

Более подробно об App Volumes 4 можно узнать на этой странице. Release Notes доступны тут.

Некоторые администраторы сталкиваются с такой конфигурацией виртуальной инфраструктуры, когда управляющий сервер VMware vCenter оказывается за NAT или сетевым экраном относительно части хостов VMware ESXi:

В этом случае получается добавить хосты ESXi в vCenter, но через примерно одну минуту они уходят в офлайн, при этом успешно пингуются. Также в течение этой минуты, пока они видны в vCenter, хосты не могут синхронизировать свою конфигурацию. Причина такого поведения проста - в агент vCenter на хостах ESXi (он же vpxa) прописывается внутренний адрес vCenter для связи со стороны ESXi.

Эти хартбиты идут на целевой порт 902 TCP/UDP (источник варьируется):

Если погуглить, то можно найти статью KB 1010652, где сказано, что такая конфигурация не поддерживается со стороны VMware.

Но есть обходной путь, который вполне работает у многих пользователей. Нужно открыть 902 порт на вашем фаерволе/NAT, а также поменять в файле конфигурации агента vCenter

/etc/vmware/vpxa/vpxa.cfg

строчку:

<serverIp>10.0.0.1</serverIp> на внешний IP-адрес вашего NAT-маршрутизатора. Также нужно добавить следующий параметр в этот файл, чтобы указанный IP не поменялся назад:

<preserveServerIp>true</preserveServerIp>

Перед редактированием файла vpxa.cfg нужно поменять права доступа командой:

chmod 744 /etc/vmware/vpxa/vpxa.cfg

а после редактирования вернуть их назад:

chmod 444 /etc/vmware/vpxa/vpxa.cfg

По окончании процедуры надо перезапустить management agents на хостах ESXi командой:

services.sh restart

И надо понимать, что данная конфигурация хоть и работает, но не поддерживается со стороны VMware. Официально для размещения vCenter за NAT workaround не существует.

Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.

Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:

• Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
• На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
• Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
• Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
• Множество исправлений ошибок и улучшений движка анализа.

Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.

На сайте проекта VMware Labs появилось еще кое-что интересное - утилита App Finder for Tunnel. С помощью данного средства можно настраивать отдельные приложения для использования функции Workspace ONE Tunnel на Mac OS.

Как известно администраторам Workspace ONE, работающим с функциями Unified Endpoint Management (UEM), для отдельных приложений можно настраивать VPN-туннель (добавить их в whitelist), чтобы не гонять через VPN весь трафик устройства пользователя.

При настройке туннеля для приложений в консоли Workspace UEM в разделе VMware Tunnel нужно настроить следующие параметры:

1. Friendly name
2. Package ID
3. Designated requirement
4. Path (используется только для некоторых дистрибутивов без зарегистрированных бандлов, таких как Curl или ssh)

App Finder for Tunnel поддерживает Drag&Drop интерфейс для перетаскивания приложений в контейнер, который дает возможность получить приведенную выше информацию о приложении и подставить ее в консоль Workspace UEM:

Для работы App Finder for Tunnel поддерживается Mac OS 10.11 или выше. Скачать утилиту можно по этой ссылке.

В сентябре этого года мы писали о новой версии пакета VMware Tools 11 для гостевых ОС виртуальных машин на платформе VMware vSphere. Одной из новых возможностей обновленной версии тулзов был читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Недавно Вильям Ламм пояснил, как именно может работать этот механизм, который дает возможность получить данные о процессах в гостевой ОС и их свойствах.

Для начала начала надо включить Application Discovery в гостевой ОС с помощью утилиты VMwareToolbox. По умолчанию этот механизм отключен, чтобы не создавать дополнительную нагрузку на виртуальную машину.

Для включения нужно выполнить следующую команду:

• Windows: VMwareToolboxCmd.exe config set appinfo enabled true
• Linux: vmware-toolbox-cmd config set appinfo enabled true

Выглядит это таким образом:

После того, как сбор данных включен, они будут обновляться каждые 30 минут - то есть эта функция не предназначена для мониторинга процессов в реальном времени, а скорее для сбора информации об имеющихся в ВМ приложениях и их свойствах. Чтобы изменить интервал обновления, используйте следующие команды:

• Linux: vmware-toolbox-cmd config set appinfo poll-interval <new value in seconds>
• Windows: VMwareToolboxCmd.exe config set appinfo poll-interval <new value in seconds>

Например, AppInfo может собирать информацию о версии всех приложений, что может оказаться полезным при автоматизированном поиске устаревших версий приложений с помощью сценариев.

Вильям написал PowerCLI-скрипт Get-VMApplicationInfo.ps1, который принимает на вход виртуальную машину, а на выходе выдает информацию о процессах гостевой ОС с меткой времени сбора данных.

Результат работы сценария можно вывести в CSV-файл или в JSON-массив.

Ну а дальше уже можно фантазировать, для чего подобная информация может пригодиться именно в вашей виртуальной инфраструктуре.

Вильям Ламм написал интересную статью про вывод информации обо всех доступных событиях на сервере VMware vCenter. Недавно мы писали о решении vCenter Event Broker Appliance (VEBA), которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Так вот, администраторы, использующие VEBA, часто задают вопрос о том, как найти конкретное событие vCenter и его ID в целях автоматизации операций. Также иногда это необходимо для использования с vSphere API. Для этого Вильям написал PowerCLI скрипт, который экспортирует список всех происходивших событий vCenter в CSV-файл, где в отдельных колонках приведены EventId, EventType (может быть Standard, EventEx или ExtendedEvent) и EventDescription:

$vcenterVersion = ($global:DefaultVIServer.ExtensionData.Content.About.ApiVersion)

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$results = @()
foreach ($event in $eventMgr.Description.EventInfo) {
    if($event.key -eq "EventEx" -or $event.key -eq "ExtendedEvent") {
        $eventId = ($event.FullFormat.toString()) -replace "\|.*",""
        $eventType = $event.key
    } else {
        $eventId = $event.key
        $eventType = "Standard"
    }
    $eventDescription = $event.Description

    $tmp = [PSCustomObject] @{
        EventId = $eventId;
        EventType = $eventType;
        EventDescription = $($eventDescription.Replace("<","").Replace(">",""));
    }

    $results += $tmp
}

Write-Host "Number of Events: $($results.count)"
$results | Sort-Object -Property EventId | ConvertTo-Csv | Out-File -FilePath vcenter-$vcenterVersion-events.csv

Пример результатов работы данного сценария как для VMware vCenter 6.7 Update 3, так и для облачной среды VMware Cloud on AWS 1.8, можно найти в репозитории по этой ссылке: https://github.com/lamw/vcenter-event-mapping.

Также можно добавить в поток событий VMware vCenter и свое собственное событие. Можно сэмулировать как стандартное событие vCenter для тестирования срабатывания алармов vCenter, так и сделать кастомное.

Вот пример сценария, который генерирует такое событие в vCenter:

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$customEvent = New-Object VMware.Vim.EventEx
$customEvent.eventTypeId = "vGhettoWelcomeEvent"
$customEvent.message = "Hello from virtuallyGhetto"
$customEvent.ChainId = "0"
$customEvent.Key = "0"
$customEvent.CreatedTime = $(Get-Date -Format g)
$customEvent.UserName = "vGhetto-Bot"

$eventMgr.postEvent($customEvent,$null)

Это событие мы увидим в консоли VMware vCenter:

На скриншоте видно, что в поле Description отображается не то, что было задано в свойствах события. Это связано с тем, что за отображение этого поля отвечает другая подсистема. Чтобы это поле корректно отображалось для кастомных событий нужно зарегистрировать кастомное расширение (custom extension), которое будет публиковать информацию о событии. Более подробную информацию об ExtensionManager, с помощью которого это можно сделать, можно посмотреть вот тут.

Вчера мы писали о новых возможностях решения для виртуализации и доставки настольных ПК и приложений VMware Horizon 7.11. Как обычно, вместе с новой версией платформы были обновлены и клиенты до версии Horizon Clients 5.3. Напомним, что о возможностях прошлых версий клиентов Horizon Clients 5.2 мы писали вот тут.

Давайте посмотрим, что нового появилось в клиентах версии 5.3:

1. Общие улучшения всех клиентов.

• Улучшение поддержки перенаправления HTTP по порту 307 – теперь в диалоговом окне показывается оригинальный URL сервера, а не тот, куда происходит перенаправление.
• Возможность кастомизировать страницу логина по протоколу RADIUS, которая появляется в Horizon Client.

2. Улучшения Horizon Client 5.3 for Windows.

• Поддержка перенаправления состояния батареи - теперь это можно установить через GPO (в шаблоне vdm_agent.admx).
• Поддержка Universal Broker - теперь можно использовать Horizon Client for Windows в окружении с брокером.
• Улучшения работы с разрешениями экрана и DPI для сервера - можно сохранить кастомное разрешение и настройки масштабирования на сервере, что позволяет соблюсти целостность при соединении через Workspace ONE Access, либо Horizon + Unified Access Gateway SAML.

3. Улучшения Horizon Client 5.3 for Linux.

• Поддержка перенаправления состояния батареи из Linux в удаленный десктоп Windows. Теперь это можно установить через GPO (в шаблоне vdm_agent.admx).
• Поддержка Red Hat Enterprise Linux 7.6 - добавлена возможность динамически подстраивать дисплеи в многомониторной конфигурации.
• Поддержка перенаправления сканера для RDSH и VDI при использовании Blast и PCoIP.
• Поддержка перенаправления HTML5 Multimedia, что позволяет рендерить видео YouTube и Vimeo на клиенте. Доступна в бета-режиме, как и VMware Printer Redirection.

4. Улучшения Horizon Client 5.3 for iOS.

• Теперь можно использовать интеграцию OPSWAT с Horizon Client for iOS путем установки мобильного приложения OPSWAT на клиентское устройство.
• Улучшения в механизме derived credentials. Теперь если вы хотите его использовать, нужно создать group policy object (GPO) в Active Directory, который соединяется с виртуальной смарт-картой через специальное middleware на уделнном десктопе.
• Работа в режиме dark mode - теперь iOS-клиент повторяет соответствующий режим в OS X.

5. Улучшения Horizon Client 5.3 for Android.

• Теперь можно добавить удаленные десктопы и приложения в избранное путем установки звездочки в окне выбора объекта.
• Установка неаутентифицированного доступа в файле JSON - теперь можно включить эту возможность, добавив свойство enable_unauthenticated_access.
• Улучшения в механизме derived credentials. Теперь если вы хотите его использовать, нужно создать group policy object (GPO) в Active Directory, который соединяется с виртуальной смарт-картой через специальное middleware на удаленном десктопе.

6. Улучшения Horizon Client 5.3 for Chrome.

• Теперь можно пометить удаленные десктопы и приложения как избранные путем добавления звездочки в окне выбора объекта.
• Установка неаутентифицированного доступа в файле JSON - теперь можно включить эту возможность, добавив свойство enable_unauthenticated_access.

Скачать клиенты VMware Horizon Clients 5.3 от релиза Horizon 7.11 можно по этой ссылке.

Компания VMware на днях обновила компоненты своей флагманской платформы для виртуализации и доставки корпоративных ПК и приложений VMware Horizon 7.11. Напомним, что прошлая версия Horizon 7.10 вышла в сентябре этого года.

Давайте посмотрим, что нового появилось в Horizon 7.11:

1. Аутентификация Horizon 7 SAML Authentication с решением VMware Unified Access Gateway 3.8.

Этот релиз Horizon включает в себя обновление механизма Security Assertion Markup Language (SAML) Authentication, который позволяет использовать одинаковый набор учетных данных для аутентификации на разных веб-сайтах. Теперь поддерживается стандарт SAML 2.0, который можно использовать отдельно или совместно с механизмом TrueSSO.

О том, как включить аутентификацию SAML 2.0 для Unified Access Gateway и Okta, можно почитать вот тут.

2. Новые REST API.

В этом релизе Horizon появилось много новых API для конфигурации и мониторинга конечных устройств, а также получения внешней информации о них. Это позволяет строить масштабируемые сценарии автоматизации, а также интегрировать сторонние решения с Horizon для выполнения административных задач.

3. Обовления Horizon Group Policy Object (GPO) Bundle.

В шаблоны групповых политик ADMX пакета Horizon GPO Bundle было внесено несколько улучшений. Также в шаблоне агента vdm_agent.admx появилось 3 новых настройки:

• Enable Battery State Redirection
• Enable UWP support on RDSH platforms
• VMware AppTap Configuration

В шаблоне клиента vdm_client.admx появилась следующая настройка:

• Save resolution and DPI to server

4. Улучшения Horizon Console.

Теперь Horizon Console на базе HTML5 является рабочим инструментом администратора по умолчанию, а также предоставляется возможность запомнить выбор и запускать HTML5-консоль всегда.

5. Прочие улучшения Horizon.

• Интегрированные службы Help Desk - утилита Help Desk Tool (Monitor > Help Desk) теперь получает больше информации из Horizon Console.
• Отображение статуса работоспособности Connection Server на дэшборде. Эта информация включает в себя использование CPU и памяти, а также показаны те серверы, что ушли в офлайн.
• Отображение прогресс-бара при выполнении операции публикации мгновенных клонов (Instant Clone Publish).
• Отображение имени приложения, к которому подключен пользователь, в разделе RDSH Sessions.
• Просмотр Global Entitlements на уровне пула десктопов. Теперь не нужно для этого отдельно заходить в раздел Global Entitlements, все теперь видно в свойствах пула.

6. Улучшения Horizon Agents.

• Улучшения Blast Extreme Blast Codec. Теперь этот кодек лучше обрабатывает контрастные края в изображениях и шрифты. Теперь он работает как полноценный видеокодек, с такими функциями, как motion detection, motion vectors и macroblocks. Кодек Blast Codec отключен по умолчанию, но вы можете включить его в ключе реестра HKLM\SOFTWARE\VMware, Inc.\VMware Blast\Config, добавив значение EncoderBlastCodecEnabled = 1. На Linux нужно включить этого кодек в настройках агента \etc\vmware\config, установив значение allowBlastCodec=TRUE.
• Механизм Blast Extreme Dynamic Encoder - теперь он позволяет динамически переключаться между кодировщиком, оптимизированным для видео, и кодировщиком для текста - как для Blast Codec, так и для режима Adaptive. Это позволяет уменьшить использование канала и динамически поддерживать нужное качество картинки в зависимости от контента. По умолчанию динамический кодировщик отключен. Чтобы включить его для Windows, нужно добавить в ветку реестра HKLM\SOFTWARE\VMware, Inc.\VMware Blast\Config значение EncoderSwitchEnabled = 1. Для Linux нужно добавить в настройки агента \etc\vmware\config, параметр allowSwitchEncoder=TRUE.
• Улучшения Horizon Agent for Windows:
  • Обновленный Skype for Business Q4 2019
  • Поддержка Red Hat 8 Linux
  • Улучшенная производительность CPU
  • Поддержка машин local security authority (LSA) при установке
• Улучшения Horizon Agent for Linux:
  • Поддержка TrueSSO на Red Hat Enterprise Linux 7 и 8

В следующей статье мы расскажем об улучшении клиентов VMware Horizon Clients 5.3 и новых возможностях VMware Dynamic Environment Management 9.10.

Скачать VMware Horizon 7.11 можно по этой ссылке.